The many lessons learned from testing the new tutorial We have already pointed out, that we are trying to make a new campaign (FFF-245), and part of it is the core beginning, the NPE/tutorial. The tutorial is one of the very critical parts of the game, as if the first 15 minutes of a game feels shitty, there is big chance that the player will not play any further. I had this experience in many games myself. So the challenge could be articulated like this: "The current tutorial is okay, but can we make it great?" The approach in the current tutorial is to feed the player with the basic knowledge of how to control the basics of the game (the first mission and the start of the second mission) in the fastest way possible. The player is even given descriptive info like this, to diminish the chance of not understanding how the basic entities work. After few steps in the 2nd level, the player can start exploring his first self-feeding loop (make iron to make more iron). The tools used to this is mainly: The message dialog that stops the game and explains the player various things. Minimization of the amount of things the player can interact with to absolute minimum, so he can't start doing other things before the basics are clear. The possible drawbacks: The constant interruptions can get really annoying (typically around 22 message dialogs before the player starts to play relatively freely in the 2nd level). The possibility, that the player will mindlessly follow the step-by step tasks without understanding it, so he can become really lost later on, and the tutorial basically wouldn't help him to understand things. So the question is: Can we make a tutorial that makes these problems go away?, and alternatively, How big are these problems actually? The current direction of the new tutorial attempt is to never use the message dialogs, so the player can learn the game more fluently, and to leave way more things to explore, as learning things yourself has a better chance of success than force-feeding generally. We made a few tests of the new approach with a few people, the main takeaway, is that nothing is for free, and this approach created new drawbacks. If the player doesn't figure out something basic, it can be very frustrating for him to figure out what is going on when not moving forward for a long time. It might be possible, that some things are just not fun to learn by exploration, and it is more comfortable if they are force fed to you. I would compare this to a friend explaining you how to play a game for 5 minutes compared to 2 hours of trial and error. There are more possible outcomes from this, and we shall see how different tweaks of both strategies work in the testings. It might be interesting if you mentioned your experience with the tutorial in the comment section as well.

Hi Factorians, This is Dominik, and my first FFF post ever! I will use this opportunity to talk to you about the exciting subject of pipes. Yeah, I know, right? Spring came and with it Twinsen, saying "Pipes suck. Two people already tried to fix it and failed, who wants to be next?", and I’m like "Hey, that’s just pipes, you just make a simple simulation, simple AF. I’m in." The conditions were even quite lenient: Fluids get where they should. They should act in a predictable manner, with reasonable splitting/joining in junctions. Fluids can travel instantly, if need be. Respect the pipe throughput limitations. Flow can be viewed on the pipes. Don’t do f**** up stuff like running in a circle indefinitely, sloshing back and forth endlessly etc. Should be faster/more UPS efficient. I am mostly working on the new GUIs, but still, the fact that summer is over and pipes are not done, kinda shows how simple fixing them is. Very naive I was.

Scan-codes vs Key-codes (posila) While migrating from Allegro to SDL, HanziQ and Jiri replaced the keystroke handling from using key-codes to scan-codes. Before you start jumping with joy, you’ll probably wonder: What is that and why should I care? Well, funny you should ask. You probably won’t care, unless you live outside of USA and/or you use a non-US keyboard layout. In short, key-code is a key identifier dependant on the symbol the key will output when pressed, scan-code is a key identifier based on the physical location of a key. So for example players with French keyboard layout (AZERTY) have to jump to the control options after launching the game for the first time, and remap movement from WASD to ZQSD, in order to be able to move their character without hurting their hand. In 0.17, the controls will map to the correct keys by default, regardless of your layout, and stay mapped to those physical keys even if you for some reason change your keyboard layout while the game is running. The disadvantage is, most of the non-US layouts didn’t end up with completely broken controls, so people kept playing with them and got used to them. So they’ll need to get used to the layout the game was originally designed with, or manually configure controls back to what they are used to. But wait, there is a catch... A few weeks ago we have announced new construction tools, which are by default bound to quite universal shortcuts (Ctrl+C for copy, Ctrl+X for cut and Ctrl+Z for undo). Bilka pointed out that the German keyboard has Z swapped with Y (as does the Czech one, but developers often don't use it) and undo incorrectly defaults to Ctrl+Y instead. To fix these kind of shortcuts we determine the appropriate default scan-codes at start-up, so that undo is always Ctrl+Z, regardless of your layout, but the action will stay bound to those keys if you change keyboard layout at runtime, which is hopefully a reasonable compromise. We might do it for other controls too (it feels natural for M to always be the default key to open the map, and T to open the technology screen), but there is another catch. It is completely reasonable for player to walk north, and Ctrl+click some entities. Remember AZERTY keyboard? Player keeps Z pressed down to walk north and presses Ctrl to start control clicking. Well, I tested this and it doesn’t trigger undo, but still stops player from walking. So it is not completely destructive, rather annoying. I am not sure how or if we’ll solve this, perhaps people with these layouts that create these kind of collisions will need resolve them by changing controls options manually.

Taming the random generatorTwinsen One of the things in the large TODO list for 0.17 is giving a final polish to the map generator. There are quite a few obvious problems now in 0.16, and some less obvious ones. Here are some of the fixes and improvements (some work in progress): All combinations of settings should no longer create strange maps such as circles of cliffs. Much more predictable starting area resources that don't overlap each-other and are not covered by water. The resource generation settings now have a much more dramatic effect (previously they had little to no effect). Increased the number of steps (small, medium, big, etc) for each setting from 5 to 9 for even more customization. The starting area will always contain water, most often a lake close to the spawn position. Since the algorithm for generating ores was pretty much completely rewritten, there are many small improvements. Now for the less obvious problem: unpredictability. I saw quite a few people complain with vague comments like "the map generator sucks". So I often asked them what the problem is in detail. Some were complaining about the above problems, some did not understand what the settings do, and some had problems finding a "good map". I saw quite a few players click "regenerate" like crazy until they got a map with fat patches in the starting area, big oil patch and also uranium, complaining that it's too hard to find a "good map". Due to the randomness we seem to have set the expectation for "good map" a bit too high. Oil and uranium were never intended to be in the starting area, but due to the randomness of the generator they sometimes were there. Also sometimes maps were so wild that you would start off either swimming in resources or desperately looking for another iron patch. It would be simple to just say "that's just RNG, deal with it", but blaming poor game experience on RNG is just bad design. So what we did is: The starting area contains only iron, copper, coal and stone, in very predictable amounts. Uranium and oil are explicitly excluded from the starting area. Starting area resources are usually in one ore patch each (depending on settings). The starting area patches are usually close together. The starting area size setting no longer affects resource placement, it just has a fixed size. Outside the starting area, the regular algorithm "kicks in" so you can still get quite wild results, but they are far enough that it averages out. I believe this is a good balance where you can still have different experiences depending on your luck, but your starting experience is much more predictable and does not leave you with the feeling that you got screwed over by the map generator. We definitely don't want the map generator to be extremely flat and predictable. Opinions on the subject are quite wild too, with people having different expectations of what a good map should look like, so we try to only make changes based on actual problems. This might seem a bit controversial so we can add an option that disables this whole starting area logic, for purists. We plan some small tweaks coming to biters also (a tiny bit more biters close to the starting area), small tweaks to terrain, cliffs, water generation and possibly some new features to make the generated trees and decoratives look better. Most of these problems including the obvious and apparently simple ones were not that easy to solve. It's hard to make random generators do what you want, so TOGoS will explain what it took to actually get it done.

With most of the team away for Gamescom or vacation, I have the pleasure of writing a Friday Facts for you this week.

Hello, A bunch of us will be travelling to Gamescom next week as visitors, if you see anybody wearing a Factorio t-shirt, it might very well be one of us. We don't have a booth or exhibit this year, as we don't want to take any focus away from the development of the game.

Hello, we had a small Factorio 0.17 LAN party this weekend. The purpose was to try and test some of the new features and play the game properly as I haven't had time for that for quite a while. I used this opportunity to think about all the smaller or bigger decisions, features or change of plans in the context of playing the game for many hours.

Hello, we are really appreciating that the new offices have proper air conditioning...

Going through to-do list (kovarex) One of the many small tasks for 0.17, was to solve the occasional problem I had when I didn't notice that one of my trains didn't have the refuelling automated. One train out of fuel can halt all the train logistics easily, and sometimes it takes quite a while to notice it. For this reason, we added an alert for trains running out of fuel when in automatic mode.

New sound design Val: Do you remember the smell of the fresh air near the seashore? Can you describe, a forest that rumbles its trees after a summer rain? All that you hear and see goes right into your mind. All of our senses are connected with each other in our memories. When we feel at least one of them, our imagination brings the others. Sometimes, and even often, we can't see the object, but we can hear it! You can't see the wind, but you feel it and hear it! The bird is singing. You can't see it hiding in a bush, but you hear a beautiful song and can define the direction it comes from. The forest, the sea, the desert... Night and day. Clanking of a loading cannon and snoring of unseen monsters. That is what we are planning to do. To put the unseen colors of sound and add some feeling of life to the planet of Factorio. Even the emptiness has it's own voice... Albert: As you probably know, we are in a stage of polishing all the possible aspects of the game. Last week we were cooperating with Val, our new sound designer, and we spent the entire week defining new concepts for environmental sounds and sound effects. Also we were working on the sound of the biter nests and the artillery cannon. This is definitely a huge subject full of details that can really improve the play experience of Factorio. Here I can show you a work in progress of the artillery cannon: We have to tweak some behaviour of the entity in order to make it act more mechanical, but overall, the possibilities that sound design can bring to the game are really interesting. Compare the simple shooting of the cannon in the actual version with this proof of concept with all those details in rotation and loading. Of course this level of detail complicates the work a little bit, but I'm convinced it's worth it.